refactor: tags, presets and custom themes read through plain getters (U5) (@miodec) - #8564

Roadmap step U5: tags, presets and custom themes get the one-getter read pattern.

Summary

Each collection module owns a module-level live query and exports plain getters. They are reactive in components and effects, synchronous everywhere else, never suspend, and return only what's loaded.

 collections/tags.ts            (same shape: presets.ts, custom-themes.ts)
-  useTagsLiveQuery()           # suspending hook, components only
-  useActiveTagsLiveQuery()
-  __nonReactive.getTags()      # escape hatch for plain code
+  createSessionDownload(...)   # this sign-in's download: loading | loaded | failed
+  tagsQuery = createRoot(() => useLiveQuery(... only once status is "loaded"))
+  getTags() / getTag(id) / getActiveTags()   # read tagsQuery.state, never tagsQuery()
+  getTagsStatus()
 collections/utils/
+  session-download.ts

• Single-row getters are fine-grained. getTag(id) reruns only when that row changes.
• Loading state uses a status, not Suspense. The settings custom themes list switches on getCustomThemesStatus(): a loading circle, the list, or "Failed to load custom themes" with a Retry button (reloadCustomThemes()).
• Callers moved to the getters:
  • commandline tag, preset and custom theme lists (they still rebuild on open);
  • the custom-themes check in config metadata;
  • the theme and preset controllers and the preset modals;
  • the settings, account, result and test-notice components;
  • results.ts.
• __nonReactive is removed from presets and custom themes. Tags keep it for test-logic and result-pb, which move in T6a/T6c.

Fixed along the way

A collection's rows outlive sign-out: the ["user"] query reset doesn't clear them. On the next sign-in the previous session's rows showed as loaded, and the blocking wait for tags and presets returned straight away with them.

 on sign in
-  collection still "ready" with the previous session's rows
+  createSessionDownload: status "loading", start the download
+  getters return nothing, waitForTagsReady/waitForPresetsReady hold
+  query succeeds → "loaded" (rows already written) | fails → "failed" (the wait still returns)

Evidence

• Before: sign in as A, sign out, sign in as B → getTags() immediately returns A's tags, reported as loaded.
  After: tags.spec "drops the previous user's tags on sign out" passes (fails on the first commit). The same holds for custom themes.
• Before: a failed custom themes download → the settings list shows the loading circle forever.
  After: "reports a failed download, and loads on reload" passes. In the browser (failure forced): the error and Retry show, and Retry brings in the 20 themes.
• Getter specs for all three collections cover:
  • sorted rows;
  • a synchronous read right after a write;
  • effects rerunning, but only for their own row;
  • empty and "loading" while signed out;
  • no GC after 10 minutes.
• Full suite: 1772 passed, and lint is clean. One earlier run had an app-shell routing test fail once; it passed on its own and in later full runs.
• Browser:
  • The commandline tag, preset and custom theme lists show.
  • Toggling a tag updates the notice above the test.
  • The settings lists refill after signing out and back in.
  • Each sign-in fetches users, custom themes and presets once each, with no duplicates.
  • The console stays clean.

Merge Danger

Door: two-way

Frontend-only refactor and fixes: no API, storage or schema changes.

Blast Radius: moderate

These three collections are read from many places: the commandline, settings, account, the result screen, the test notice, the theme controller and the preset controller. Possible problems:

• the custom themes list could show a loading state where it used to be briefly empty;
• sign-in now waits for this session's tags and presets download, not just the first one.

Spec updated in this PR: Server data, Intended deviations ("From user data (U5)") and Q28.

🤖 Generated with Claude Code